In cellular communication, the most basic form of “handover” or “handoff” is when a phone call in progress is redirected from its current cell, which is called a “source cell” or “serving cell”, to a new cell (called “target cell”). In terrestrial cellular radio networks, the source and the target cells may be served from two different cell sites or from a single cell site. In the latter case, the two cells are usually referred to as two “sectors” on the cell site. Such a handover (HO), in which the source and the target cells are different cells—even if they are on the same cell site—is called an inter-cell handover. The purpose of an inter-cell handover is to maintain the call as the subscriber is moving out of the area covered by the source cell and entering the area of the target cell.
FIG. 1 illustrates certain network interfaces—i.e., the “S1,” “X2”, and “Uu” interfaces—in a Third Generation Partnership Project's (3GPP) Long Term Evolution (LTE) network 15. These network interfaces may be relevant during a handover. The LTE network 15 is shown to include a source cell 17 having a source/serving evolved Node B (eNB or eNodeB) or Radio Base Station (RBS, or more simply “BS”) 18 associated therewith, and a target cell 20 having a target eNB or BS 21 associated therewith. For the sake of simplicity, only two cells—the serving cell 17 and the target cell 20—are shown in FIG. 1 as part of the network 15. It is understood that many such cells may form part of the network 15, and inter-cell handovers among those cells allow a UE, for example, the UE 23, to “seamlessly” continue mobile communication throughout the network 15 and beyond. As mentioned earlier, the cells 17 and 20 may be part of different cell sites (not shown) or may belong to the same cell site (not shown). Furthermore, although cells 17 and 20 are illustrated far apart in FIG. 1 and although UE 23 is shown outside of both of these cells 17, 20, such illustration is for the sake of convenience and ease of discussion only. In the context of the handover related discussion with reference to FIG. 1, it is understood that the UE 23 may be physically present and operating (or registered) within the serving cell 17 or may be currently associated with—i.e., under Radio Frequency (RF) coverage of—or attached to the serving cell 17 in some manner such as, for example, through a prior handover. The UE 23 may now need to be handed over to the target cell 20 if so determined by the serving eNB 18 associated with the source cell 17 and providing RF coverage to the UE 23 within the source cell 17. The target eNB 21 may provide RF coverage over cell 20 and in its vicinity.
In LTE, the communication interface between the serving eNB 18 and the target eNB 21 is called the “X2” interface, which may be used to carry out necessary HO-related signaling. The X2 communication interface between two eNBs 18, 21 is symbolically illustrated by line 25. The radio interface between the UE 23 and an eNodeB is called the “Uu” interface in LTE. The “Uu” interfaces to source and target eNBs are symbolically illustrated by radio links 27-28 in FIG. 1.
As shown in FIG. 1, the LTE network 15 may also include a Core Network (CN) 30, which may be an Evolved Packet Core (EPC). In FIG. 1, the block showing the CN 30 is shown dotted to indicate lack of any appreciable involvement of many of its component nodes during a handover operation. However, a management node 32 in the CN 30 may be needed to facilitate handover. In the EPC, the management node 32 may include the functionalities of a Mobility Management Entity (MME) and a Serving Gateway (S-GW). For ease of discussion, the MME and S-GW are not illustrated separately in FIG. 1. However, it is understood that the MME and the S-GW may be separately implemented in the CN 30. As noted earlier, the eNBs 18, 21 may be interconnected with each other by means of the X2 interface. Furthermore, the eNBs 18, 21 also may be connected to the CN 30 such as, for example, the EPC in LTE, by means of the “S1” interface as symbolically illustrated by lines 34-35 in FIG. 1. More specifically, the S1 interface may include two separate interfaces—the interface “S1-MME” connecting an eNB to the MME in the CN 30, and the interface “S1-U” connecting an eNB to the S-GW in the CN 30. It is noted here that the S1 interface supports a many-to-many relation between MMEs/S-GWs and eNBs.
X2 and S1 Handovers
FIG. 2 shows an operational sequence 38 for X2 handover in an LTE network, whereas FIG. 3 (discussed later below) shows an operational sequence 54 for S1 handover in an LTE network. The LTE network may be the network 15 in FIG. 1. The term “X2 handover” may refer to the handover related messaging across the X2 interface connecting the source and the target eNBs 18 and 21, respectively. On the other hand, the term “S1 handover” may refer to the handover related messaging across the respective S1 interfaces 34, 35 for the source and target eNBs 18, 21. A detailed description of various messages shown in the operational sequences 38, 54 in FIGS. 2 and 3, respectively, may be obtained from a number of 3GPP Technical Specifications (TS) such as, for example, the 3GPP TS 36.133, version 12.3.0 (March 2014), titled “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Requirements for support of radio resource management (Release 12)”; the 3GPP TS 36.331, version 12.2.0 (June 2014), titled “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification (Release 12)”; the 3GPP TS 36.413, version 12.2.0 (June 2014), titled “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP) (Release 12)”; and the 3GPP TS 36.423, version 12.2.0 (June 2014), titled “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 application protocol (X2AP) (Release 12).” The relevant portions of these 3GPP TSs are incorporated herein by reference in their entireties. Because of significant details of the HO operation in these 3GPP TSs, only a brief discussion of the operational sequences in FIGS. 2 and 3 is provided below.
It is noted here that the messaging in FIGS. 2-3 is shown in the context of the network configuration in FIG. 1. Hence, the same reference numerals are used in these figures to refer to the same/similar entities. Furthermore, for ease of discussion, the management node 32 is depicted using two separate entities 32a, 32b in FIG. 2, and four separate entities 32a-32d in FIG. 3. However, these separate entities may be implemented using a single node or multiple nodes in the CN 30. Also, in one embodiment, in the context of FIG. 3, the target MME 32d and the target S-GW 32c may be part of a core network (not shown) that is different from the CN 30.
In the discussion below, a “cell” and its associated eNB may be referred to in an interchangeable manner. For example, a UE may be interchangeably referred to as being handed over to a target cell or a target eNB, or an HO may be interchangeably referred to as being initiated by a source cell or a source eNB, and so on.
Referring now to FIG. 2, in the RRC_Connected state—which is symbolically illustrated using the reference numeral “40”—the source eNB 18 may send, at arrow 42, an “RRC Connection Reconfiguration” message to the UE 23 containing information about Signaling Radio Bearers (SRBs) that are setup by the source eNB 18 for RRC messages and about the neighbor cell measurement configuration that the UE 23 should use to perform measurements on the neighboring cells and to report the measurements to the source eNB 18. The SRBs are typically defined as Radio Bearers (RBs), which are discussed in more detail later with reference to FIG. 4. An HO is a procedure that changes the serving cell of a UE in RRC_Connected state. As is known, when the UE 23 is mobile, it may start receiving RF signals from the eNB 21 in the target cell 20 along with the RF signals from its serving cell 17, especially when the UE 23 is in the vicinity of the target cell 20. The source eNB 18 may thus instruct the UE 23 attached to the serving cell 17 and under operative control of the eNB 18 to perform certain measurements on the target cell 20. The eNB 18 may use different policies for instructing the UE 23 to do the measurements and when to report them to the eNB 18. In FIG. 2, the dotted arrow 43 shows a data plane that has been established between the UE 23 and the S-GW 32a in the CN 30 to continue supporting UE's data transfers while the HO-related RRC messaging occurs among the UE 23, the source eNB 18, and the target eNB 21. The data transfers may be associated with a service that is currently being received by the UE 23 through the source cell 17. The service may be, for example, a voice call, a multimedia content download, online messaging, and the like.
When the UE 23 receives RF signals from the target cell 20, the UE 23 may report target cell's signals measurements, as received by the UE 23, to its serving cell 17 using an “RRC Measurement Report” at arrow 44. The UE's Measurement Report may identify a candidate eNB—here, the target eNB 21—for handover. The UE 23 may perform measurements on the neighbor cells, such as the target cell 20, by measuring their Reference Symbols Received Power (RSRP), Reference Symbols Received Quality (RSRQ), and so on. In the embodiment of FIG. 2, the message at arrow 44 may indicate that the UE 23 is reporting an “A3” event, which refers to a situation when the UE 23 is receiving signals from the target cell 20 that are better than the signals from its serving cell 17 by a predefined offset. Various other “events” that may trigger measurement reporting by a UE are defined in section 5.5.4 of the earlier-mentioned 3GPP TS 36.331. Some exemplary triggering “events” such as the Event A2, the Event A5, and the Event B2 are discussed later with reference to discussion of FIGS. 9-11.
At block 45, the source eNB 18 may make a decision whether to handover the UE 23 to the target eNB 21 or not based on the Measurement Report received from the UE 23. Upon determining that the UE 23 is to be handed over to the target cell 20, the source eNB 18 may send, at arrow 46, an “X2 Handover Request” to the target eNB 21 with a list of EUTRAN Radio Access Bearers (E-RABs or ERABs) to be admitted by the target eNB 21 as part of the handover. An E-RAB uniquely identifies the concatenation of an S1 bearer and the corresponding data radio bearer as illustrated in FIG. 4 and discussed later below. The admission of a specific E-RAB by the target cell 21 assures UE's 23 continued “link” to the core network 30 for data transfers associated with a service that is currently being received by the UE 23 through the source cell 17. As mentioned earlier, the service may be, for example, a voice call, a multimedia content download, online messaging, and the like. At step 47, the target eNB 21 may perform admission control for each ERAB individually. A more detailed discussion of such admission control is provided later below.
In the embodiment of FIG. 2, a timer 48 may be activated by the source eNB 18 to monitor the time it takes for a response to the handover request to be received from the target eNB 21. The handover procedure may be canceled by the source eNB 18 if the response is not received within a predetermined time period. It is shown in FIG. 2 that a response—in the form of an “X2 Handover Request Acknowledge” message at arrow 49—may be received from the target eNB 21 before the timer 48 expires. The Handover Acknowledge message from the target eNB 21 may contain a list of ERABs acknowledged/admitted by the target eNB 21 and the ERABs rejected (or failed to be admitted) by the target eNB 21. Thereafter, at arrow 50, the source eNB 18 may initiate the handover by sending an “X2 Sequence Number (SN) Status Transfer” message to the target eNB 21 before commencing the forwarding of UE data (at block 51 in FIG. 2) to the target eNB 21. To inform the UE 23 of the handover, the source eNB 18 may send an RRC Connection Reconfiguration message—which is not shown in FIG. 2, but may be similar to the message shown at arrow 70 in FIG. 3—to the UE 23 indicating the target eNB to which the UE 23 should handover to.
Referring now to FIG. 3, the S1 handover in the RRC_Connected state may commence with an “RRC Connection Reconfiguration” message from the source eNB 18 to the UE 23 at arrow 55. The operations 55 through 58 are identical to operations 42-45 in FIG. 2, respectively, and, hence, operations 55-58 are not discussed herein. As shown in FIG. 3, at arrow 59, an “S1 Handover Required” message may be sent from the source eNB 18 to the source MME 32b containing information about the target eNB 21 to which the UE 23 is to be handed over as well as the ERABs to be admitted by the target eNB 21. In the embodiment of FIG. 3, a timer 60 may be implemented at the source eNB 18 to monitor the time it takes for a response to the S1 Handover Required message to be received from the source MME 32b. The source eNB 18 may consider the handover procedure as “failed” if the source eNB 18 does not receive such a response within a predetermined time period. Upon receiving the handover required message at arrow 59, the source MME 32b may send an “S10 Forward Relocation Request” to the target MME 32d as indicated by arrow 61. In response, the target MME 32d may exchange an “S11 Create Session Request/Response” messaging with the target S-GW 32c as indicated by the bi-directional arrow 62. Once a UE-specific session for the target eNB 21 is created at the target S-GW 32c—as indicated by the S11 Create Session Response message from the target S-GW 32c to the target MME 32d, the target MME 32d may send an “S1 Handover Request” to the target eNB 21 as indicated at arrow 63. The HO request at arrow 63 may specify the ERABs to be admitted by the target eNB 21. In response to the handover request from the target MME 32d, at block 64, the target eNB 21 may perform admission control for each ERAB individually. As noted earlier, a more detailed discussion of such admission control is provided later below.
Upon conclusion of admission control, the target eNB 21 may send a response—in the form of an “S1 Handover Request Acknowledge” message at arrow 65—to the target MME 32d. This HO Acknowledge message from the target eNB 21 may contain a list of ERABs acknowledged/admitted by the target eNB 21 and the ERABs rejected (or failed to be admitted) by the target eNB 21. Thereafter, at arrow 66, the target MME 32d may send an “S10 Forward Relocation Response” message to the source MME 32b corresponding to the earlier-sent S10 Forward Relocation Request at arrow 61. The response at arrow 66 may contain information about ERABs admitted by the target eNB 21. The source MME 32b may, in turn, send an “S11 Create Bearer Request” message to the source S-GW 32a and receive an “S11 Create Bearer Response” message from the source S-GW 32a as indicated by the bi-directional arrow 67. The message exchange at arrow 67 would create bearer resources at the source S-GW 32a for transfer of the target eNB-admitted ERABs to the target S-GW 32c where a UE-specific, target eNB-based HO session is already created as noted at arrow 62. Thereafter, a User Plane (UP) may be established between the source S-GW 32a and the target S-GW 32c for UE data forwarding as indicated by the dotted bi-directional arrow 68.
To effectuate the handover, the source MME 32b may provide the source eNB 18 with an “S1 Handover Command” at arrow 69. Consequently, to inform the UE 23 of the successful setup of the handover, the source eNB 18, at arrow 70, may send an “RRC Connection Reconfiguration” message to the UE 23 indicating the target eNB to which the UE 23 should handover to. The message at arrow 70 may provide the UE 23 with an HO command and may also include the neighbor cell measurement configuration similar to the message at arrow 55. The UE 23 can use the measurement configuration to perform measurements on the neighboring cells and report the measurements to the source eNB 18 prior to attaching to the target eNB 21 as part of the handover.
It is pointed out here that although the operations in FIGS. 2-3 are shown numbered in sequence of “1”, “2”, “3”, and so on, such numbering is for illustration and ease of discussion only and does not imply any strict sequential execution of these steps. In alternative embodiments, certain steps may be absent or may be executed in a different order. Furthermore, as mentioned earlier, the source and target S-GWs and MMEs 32a-32d may be part of the same core network, for example, the CN 30 in FIG. 1, or part of the different source and target core networks when the source and target eNBs are controlled by different core networks. Also, these S-GWs and MMEs may be implemented as different nodes in their respective core network(s). However, for ease of discussion herein, the nodes 32a-32d in FIGS. 2-3 are considered as being represented by the “common” network entity 32 in the CN 30 in FIG. 1. In one embodiment, the source and the target eNBs 18, 21, respectively, may be served by the same S-GW and the same MME in the core network 30. Additional different configurations may be possible depending on the implementation of an operator's LTE network.
It is noted here that, in certain embodiments, a network operator may not have configured or implemented an X2 interface between the source eNB 18 and the target eNB 21. In that case, only the S1 handover procedure of FIG. 3 may be carried out. In other words, the X2 HO procedure of FIG. 2 may be optional in an LTE network, but the S1 HO procedure of FIG. 3 may not be.
Admission Control
An LTE network is an all-IP (Internet Protocol) network that is designed to support end-to-end Quality of Service (QoS). Therefore, the purpose of admission control, such as, for example, the admission control at block 47 in FIG. 2 and at block 64 in FIG. 3, is to control admission of UEs and E-RABs in such a way that requested QoS can be achieved for the UE or E-RAB seeking admission in the target cell, as well as for the UEs and E-RABs previously already admitted. A detailed discussion of different types of bearers and associated QoS parameters is provided, for example, in Section 13 of the 3GPP TS 36.300, version 12.2.0 (June 2014), titled “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (Release 12),” the relevant portions of which are incorporated herein by reference in their entireties. In view of the details in this 3GPP TS 36.300, only a brief overview of QoS and admission control is provided below.
FIG. 4 illustrates a bearer architecture 75 depicting some exemplary bearers that may be used to transport packets in an LTE network such as, for example, the LTE network 15 in FIG. 1. For ease of discussion, the bearer architecture 75 is shown in the context of the source eNB 18 and source S-GW 32a. However, it is understood that such bearer architecture also may exist involving the target eNB 21 and target S-GW 32c. In FIG. 4, the UE 23 and the source eNB 18 are shown to comprise an E-UTRAN portion 77 of the LTE network 15, whereas the CN 30 is an Evolved Packet Core (EPC). Together, the E-UTRAN portion 77 and the EPC 30 may be considered to form an Evolved Packet System (EPS). It is understood that many other network nodes or entities may be part of the E-UTRAN portion 77 and the EPC 30 in the CN 30, but, for the sake of simplicity and ease of discussion, only the relevant nodes/entities are shown in FIG. 4. Also, as discussed in more detail in the earlier-mentioned 3GPP TS 36.300, there may be additional bearers above the E-RAB 79 in the hierarchy of bearers in FIG. 4, but such bearers are not shown in FIG. 4 because their lack of relevance to the present disclosure.
In the all-IP LTE network 15, an E-RAB, such as the E-RAB 79, may transport the packets of an EPS bearer (not shown) between the UE 23 and the EPC 30. In the hierarchy of bearers in FIG. 4, an EPS bearer may be logically implemented “above” the E-RAB 79. When an E-RAB exists, there is a one-to-one mapping between this E-RAB and its corresponding EPS bearer. A data radio bearer 81 may transport the packets of the E-RAB 79 between the UE 23 and the source eNB 18. When a data radio bearer exists, there is a one-to-one mapping between this data radio bearer and the E-RAB 79. An S1 bearer 83, on the other hand, transports the packets of the E-RAB 79 between the source eNB 18 and its corresponding source S-GW 32a. Thus, the E-RAB 79 uniquely identifies the concatenation of the S1 bearer 83 and its corresponding data radio bearer 81, thereby providing a “seamless” connection for packets exchanged between the UE 23 and the EPC 30 such as, for example, the packets that are sent to/received from the UE 23 as part of the service—like a voice call—being provided to the UE 23 through the source eNB 18. An E-RAB provides for bearer-level QoS control in the EPC/E-UTRAN. Thus, a packet mapped to the same ERAB would receive the same bearer level packet forwarding treatment such as, for example, scheduling policy, queue management policy, QoS, Radio Link Control (RLC) configuration (which is briefly discussed later below), and the like.
In the LTE network 15, one ERAB may be established when the UE 23 initially connects to the EPC 30, and that ERAB remains established throughout the lifetime of the UE's connection to the EPC 30 to provide the UE 23 with an “always-on” IP connectivity. Such an E-RAB may be referred to as a “default bearer.” On the other hand, any additional E-RABs that are established to support the QoS requirements of one or more services being used by the UE 23 in the network 15 may be referred to as “dedicated bearers.” The bearer-level QoS parameter values of these ERABs may be assigned by the EPC 30 based on, for example, the UE's 23 subscription data. The establishment, modification, and release of E-UTRAN resources for ERABs may be performed under the control of the EPC 30, more specifically, the source MME 32b in the EPC 30.
An E-RAB may be referred to as a Guaranteed Bit Rate (GBR) bearer if dedicated network resources related to a GBR value associated with the E-RAB are permanently allocated, for example, by an admission control function in an eNB, at the time of bearer establishment/modification. The GBR value may be associated with the QoS requirements in a UE's subscription data. An ERAB that is not a GBR bearer may be referred to as a non-GBR bearer. A dedicated bearer can either be a GBR or a non-GBR bearer, whereas a default bearer is generally a non-GBR bearer.
As discussed in more detail in the earlier mentioned 3GPP TS 36.300, bearer-level QoS parameters may include QoS Class Identifier (QCI), Allocation and Retention Priority (ARP), and GBR, among others. Each ERAB (GBR and non-GBR) may be associated with these bearer-level QoS parameters. Various QCI values are shown in FIG. 5, which is discussed below. The QoS parameter ARP decides whether a bearer establishment/modification request can be accepted or needs to be rejected in case of resource limitations. Thus, the ARP can be used by an eNB such as, for example, the target eNB 21 in FIG. 1 to decide which bearer(s) to admit and which ones to drop, for example, during an HO, because of resource limitations. Thus, the admission control of ERABs is dependent on availability of network resources at the target eNB. The ARP contains information about the priority level of a UE's data traffic. The range of ARP priority level is “1” to “15”, with “1” being the highest level of priority. The data traffic having a certain level of GBR requirement may have a corresponding ARP priority level associated therewith. The ARP priority level may be used by the target eNB 21 during an HO to decide which existing bearer(s) to pre-empt due to resource limitations so as to accommodate the source eNB's request to admit a specific ERAB.
Admission control at the target eNB 21 may be performed at RRC Connection Setup, EPS Bearer Setup Handover Request, and EPS Bearer Modification procedures. To accomplish the requested QoS for UEs and E-RABs, the Admission Control functionality at the target eNB 21 may reject UE and E-RAB admission requests on the S1/X2 interfaces based on whether the target eNB's 21 system resources are congested. As noted above, different bearers can be given different priorities based on settings of ARP. This enables to prioritize and protect certain services in case of resource shortage. Lower priority bearers can be released/pre-empted in order to serve the UEs having higher priority bearers.
There are three major types of Admission Control procedures defined in relevant 3GPP specifications: (i) Admission Control for Transmission/Transport network, (ii) Dynamic GBR Admission Control for Radio Network, and (iii) Differentiated Admission Control for ARP based pre-emption. A transmission or transport network exists between an eNB and the MME/S-GW in the core network to which the eNB is connected via an S1 interface. The transmission network may thus include the IP backhaul resources. A radio network, on the other hand, exists between a UE and an eNB.
Admission control algorithms are based on a set of metrics referred to as Monitored System Resources (MSRs). An MSR is a metric that represents a limited system resource that needs to be explicitly monitored to ensure correct and efficient operation of the admission and congestion control procedures at a target eNB. Thus, MSRs include resources such as Physical Resource Blocks (PRBs), Scheduling Elements (SEs), Control Channel Element (CCE), and baseband capacity. The use of the MSRs may be measured by a target eNB—such as the target eNB 21 in FIG. 1—during a measurement period, after which a filtered value for the MSR usage may be calculated. This filtered MSR usage value may be updated after each new measurement period.
The transport network admission control ensures that the sum of GBR (from each ERAB request in S1AP/X2AP procedures) of the admitted ERABs (at a specific target eNB) does not exceed the admission thresholds configured for that target eNB. The S1AP and X2AP procedures are discussed in more detail, for example, in the earlier-mentioned 3GPP TS 36.413 and 36.423, respectively.
RLC Transmission Modes
Radio Link Control (RLC) protocol for the UE-E-UTRAN radio interface is described in more detail in the 3GPP TS 36.322, version 12.0.0 (June 2014), titled “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Link Control (RLC) protocol specification (Release 12).” In view the detailed discussion in the 3GPP TS 36.322, only a brief overview of RLC transmission modes is provided herein.
Functions of the RLC sub-layer are performed by RLC entities. For an RLC entity configured at the eNB, there is a peer RLC entity configured at the UE, and vice versa. An RLC entity receives/delivers RLC Service Data Units (SDUs) from/to upper layer and sends/receives RLC Protocol Data Units (PDUs) to/from its peer RLC entity via lower layers. The RRC functionality—in the UE and in the eNB—is generally in control of the RLC configuration. An RLC entity can be configured to perform data transfer in one of the following three modes: (i) Transparent Mode™, (ii) Acknowledged Mode (AM), and (iii) Unacknowledged Mode (UM). Consequently, an RLC entity is categorized as a TM RLC entity, an UM RLC entity, or an AM RLC entity depending on the mode of data transfer that the RLC entity is configured to provide. The RLC™ mode is not relevant to the HO-related discussion herein and, hence, is not addressed below.
For RLC UM bearers, both RLC Sequence Number (SN) and Packet Data Convergence Protocol (PDCP) SN are reset at handover and the target eNB starts sending UM packets with PDCP SN starting from “0.” However, the RLC mode of the bearers must not be changed during handover. If the RLC mode of the bearers is different in the source and the target eNBs, then the bearers are not set up in the target eNB. It is noted here that RLC mode is configured for each QCI by an eNB. Thus, if the source eNB 18 (FIG. 1) has a bearer with QCI configured with the RLC UM feature and the target eNB 21 has mapped the same QCI to RLC AM, the bearer will be rejected by the target eNB 21 during HO. Similarly, if the target eNB has an invalid RLC in UM feature license, the HO can only be performed with RLC AM bearers. The UM bearers will be rejected by the target eNB.
QCI Values
As noted earlier, QCI values provide a mechanism for QoS support in LTE. QCI is a scalar that is used as a reference to node-specific parameters that control packet forwarding treatment and that have been pre-configured by the operator owning/operating the node such as, for example, the source eNB 18 or the target eNB 21 in FIG. 1. The packet forwarding treatment may include, for example, scheduling weights, queue management thresholds, packet loss rate, packet delay budget, link layer protocol configuration, and so on. In LTE, each IP bearer—for example, an ERAB—has an associated QCI value that determines how the bearer is handled in the LTE eNodeBs such as, for example, the eNBs 18 and 21 in FIG. 1, and in the EPC 30.
FIG. 5 shows a table 85 listing currently-standardized QCI values in LTE for different types of wireless communications. A more detailed version of the table 85 may be obtained by consulting, for example, the table 6.1.7 in 3GPP TS 23.203, version 11.8.0 (Dec. 2012), titled “3GPP: TS Group Services and System Aspects; Policy and Charging Control Architecture (Release 11).” Standardization of a QCI with corresponding characteristics such as “Resource Type” of the QCI, “Priority” level for the QCI, and the like, ensures that applications/services mapped to that QCI receive the same minimum level of QoS in multi-vendor network deployments and also in case of roaming, regardless of a UE's current access (3GPP or non-3GPP).
In FIG. 5, the one-to-one mapping between nine (9) standardized QCI values and some of the standardized characteristics is shown. The standardized characteristics shown in FIG. 5 include (i) the “Resource Type” of a particular QCI value—i.e., whether the QCI value is a Guaranteed Bit Rate (GBR) QCI value or a non-GBR QCI value, and (ii) a “Priority” level associated with that QCI value. The “Resource Type” (or, simply the “Type”) may determine if dedicated network resources such as, for example, radio resources, related to a service or bearer level GBR value are permanently allocated. As shown in FIG. 5, every QCI (GBR and non-GBR) is associated with a “Priority” level, which may be used as a basis for assigning the uplink (UL)/downlink (DL) priority per radio bearer. The “Priority” level is provided on a scale of “1” through “9.” Priority level “1” is the highest priority level, and priority level “9” is the lowest priority level. Thus, for example, it is seen from the table 85 in FIG. 5 that the non-GBR QCI value=5 as the highest priority level, whereas the non-GBR QCI value=9 has been assigned the lowest priority level. The non-GBR QCI value=5 may be related to IP Multimedia Subsystem (IMS) related signaling traffic, whereas the non-GBR QCI value=9 may be related to buffered streaming of video data or Transmission Control Protocol (TCP)-based data such as, for example, World Wide Web (www) surfing, e-mail, chat, File Transfer Protocol (FTP) file transfer, Person-to-Person (P2P) file sharing, and the like. Other service applications such as, for example, conversational voice, real-time gaming, and so on, have priority levels between these two ranges as shown in FIG. 5. For the sake of brevity, these services and their associated Resource Types and Priority levels are not discussed here in view of the details shown in the table 85 in FIG. 5.